Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dip-213] decoupled execution #214

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[dip-213] decoupled execution #214

wants to merge 1 commit into from

Conversation

zekun000
Copy link
Contributor

@zekun000 zekun000 commented Nov 24, 2021

for #213

Copy link
Contributor

@dahliamalkhi dahliamalkhi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wonderful proposal! see stylistic/clarification comments inline.

dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated
To prevent consensus going too fast and create ever-growing backlog for other stages, back pressure is implemented to stop consensus making progress if the difference between committed block and ordered block is large.

## Reconfiguration
A reconfiguration transaction is the last transaction of an epoch. Execution recognizes this type of transaction and buffer manager would stop processing any blocks after the reconfiguration block.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
A reconfiguration transaction is the last transaction of an epoch. Execution recognizes this type of transaction and buffer manager would stop processing any blocks after the reconfiguration block.
Recall that a reconfiguration transaction must be the last transaction of an epoch. Execution recognizes this type of transaction and BufferManager stops processing blocks succeeding the reconfiguration block.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about the empty/special block that must follow a reconfiguration block to reach a 2-chain commit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those empty blocks won't be committed (both before and after), they're just used to facilitate the commit of reconfiguration block.

dips/dip-213.md Outdated

## Reconfiguration
A reconfiguration transaction is the last transaction of an epoch. Execution recognizes this type of transaction and buffer manager would stop processing any blocks after the reconfiguration block.
Consensus would stop once the backpressure is triggered, blocks after the reconfiguration block would be discarded and transactions would be retried in next epoch.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not clear. Please explain

dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated
`StateComputer` is the trait that consensus uses for `compute`, `commit` or `sync_to` blocks.
A simple `ordering_state_computer` is implemented to bypass execution and send blocks to next stage when ordered.

## BufferManager
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's really a block state-machine, but that's of course overloaded.

how about ConsensusStageManager or BFTStageManager or SMRStageManager?

dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Outdated Show resolved Hide resolved
dips/dip-213.md Show resolved Hide resolved
dips/dip-213.md Show resolved Hide resolved
dips/dip-213.md Outdated
Recall that a reconfiguration transaction must be the last transaction of an epoch. Before this proposal, consensus-ordering is aware of
reconfiguration and leader proposes empty suffix. After the proposal, execution on each node recognizes this type of transaction and BlockStateManager stops processing any blocks succeeding the reconfiguration block.
Ordered blocks after the reconfiguration block are discarded and transactions inside those blocks would be retried in next epoch.
Imagine a few block batches [1, 2] [r, 3], [4], [5, 6], r represents a block has reconfiguration transaction. The ledger info is aggregated on block 3 (transactions in 3 are skipped) and 4, 5, 6 are discarded.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the purpose of the bracket notation? what do you mean by "block batches" (transactions batched into blocks?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Imagine a few block batches [1, 2] [r, 3], [4], [5, 6], r represents a block has reconfiguration transaction. The ledger info is aggregated on block 3 (transactions in 3 are skipped) and 4, 5, 6 are discarded.
Imagine a few block batches [1, 2] [r, 3], [4], [5, 6], r represents a block that contains a reconfiguration transaction. The ledger info is aggregated on block 3 (transactions in 3 are skipped) and 4, 5, 6 are discarded.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a batches of blocks that certified by a ledger info, not every block gets a ledger info in case of timeout

dips/dip-213.md Outdated
After the reconfiguration block gets committed, the old epoch instance is dropped, a new epoch is instantiated via a virtual genesis block derived from the last ledger info in previous epoch.

## Upgrade
To enable the feature in existing blockchain requires coordination via reconfiguration, on-chain consensus config would be updated to a newer version supporting the upgrade protocol.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To enable the feature in existing blockchain requires coordination via reconfiguration, on-chain consensus config would be updated to a newer version supporting the upgrade protocol.
To enable the feature in an existing blockchain requires coordination via reconfiguration, on-chain consensus config would be updated to a newer version supporting the upgrade protocol.


## Reconfiguration
Recall that a reconfiguration transaction must be the last transaction of an epoch. Before this proposal, consensus-ordering is aware of
reconfiguration and leader proposes empty suffix. After the proposal, execution on each node recognizes this type of transaction and BlockStateManager stops processing any blocks succeeding the reconfiguration block.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this mean that the consensus stage continues moving forward, oblivious of the reconfiguration transaction, until either execution catches up with the reconfig tx or back-pressure prevents progress? if yes, perhaps add this clarification to the text?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it moves forward until it hits backpressure and then blocks until next epoch

Copy link

@mimoo mimoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wow this is great, is this implemented already? Are there any downsides of this approach?

- `Ordered` block is sent to execution and advanced to `Executed` after receiving execution result.
- `Executed` block is sent to safety rules and advanced to `Signed` after receiving a signature.
- Signature on `Signed` block is broadcasted to all validators. At all stages except `Aggregated`, signatures from other validators on the block are collected.
- A block in either `Executed` or `Signed` stage is advanced to `Aggregated` after receiving a quorum of signatures.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest "certification of correct execution", as 2f+1 have agreed that this is the correct execution output

@zekun000
Copy link
Contributor Author

@mimoo yes it's already implemented. one trade-off is that it adds one hop latency due to the extra execution certification

@mimoo
Copy link

mimoo commented Mar 16, 2022

oh right, makes sense! thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants